I've written a simple perl script using SOAP to add some useful data to the RC bug list (or any list of bugs). It can easily be extended but right now it supports simple things like the date the bug was filed, short description of the package, the name of the maintainer, the most recent upload data, the debtags for the package, apt-cache policy data and whether the bug is already tagged pending.
Zenity presents this info in a question dialog, clicking OK loads the bug and the PTS in your browser using 'sensible-browser'.
Clicking cancel offers a new zenity dialog asking for the next bug number. (Click Cancel there to end the script.)
Code: http://linux.codehelp.co.uk/rc-zenity.pl (GPLv3 or later)
POD: http://linux.codehelp.co.uk/rc-zenity.html (easily convertible into a manpage using pod2man)
If you like it, use it.
If lots of people like it, maybe it can go into an existing package.
If I've duplicated another script that I just didn't know about, tell me.

It's not exclusively for RC bugs, it could work with any bug list or be modified to only look for particular severity settings.
Thanks to Don Armstrong for making debbugs so accessible using SOAP. The debbugs SOAP implementation is just so straightforward with a whole load of useful data returned without needing repeated queries, it makes scripts like this really satisfying.

I took a note of the various talks I attended at DebConf, with the aim of writing a few notes about each so that I could try to explain to my work mates exactly what I get out of going. However I think a lot of the benefit is about general face to face contact with fellow DDs and random conversations that happen. Having worked from home for over 3 years I'm finding it quite nice to be back in an office with people working on the same things as me; there are conversations that you will have over a quick cup of coffee or in the corridor that you wouldn't bother typing on IRC or email or picking up the phone for. Debian is a lot like a large organisation full of telecommuters and DebConf provides a vital opportunity for us to have those "minor" conversations that prove quite useful and to remind each other what we're actually like in person. I didn't end up writing a lot of notes during the talks so these are just snippets after the fact. If I'd been more organised I'd have done a write up on a daily basis rather than leaving it all until the week after. A lot of the below is fragmented thoughts, but the longer I leave it the less relevant it gets and the more chance I forget something. It'd have been up faster if I hadn't been fighting Movable Type to try and get some sort of headings. Sunday
Introduction, Marga The "Welcome to DebConf" bit. Marga got up and talked about how at DebConf4 (Brazil) she hadn't been a DD and now she was and how it had been a life changing event. She'd thought she was to blame for DebConf8 in Argentina, but trawling mail archives had shown it was originally Mart n's idea. She hadn't realised at the start quite how much work it would be. Steve's DPL talk, Steve McIntyre The DPL welcomes us to DebConf and talks about Debian's achievements, some of the results of his team survey (the teams largely say they need more manpower. Not really a huge surprise.). NM/User Survey BOF, Paul Wise Paul emailed debian-user, debian-newmaint and various other places (I think) asking about people's experiences as a Debian user or applicant to New Maint. His final results aren't yet published and I got the impression a disappointing number of our users had replied. The NM problems these days seem to be largely down to a lack of AMs, at least according to the stats on nm.debian.org. Meet SPI board - bdale, maulkin, jimmy, michael, others A chance to meet those of the SPI board who were present. The usual "If you're involved with Debian you should seriously consider joining SPI". Some discussion about the fact that although SPI was originally mostly Debian these days other projects are making more and more use of it - OFTC, PostgreSQL and Madwifi for example. Not a huge amount of new information for me. I've been an SPI member for some time and I think they perform a vital role for Debian. They've had issues in the past but it's really good to see them overcome and more projects on board. Monday
http://hp.com/go/debian, bdale Bdale talks about the history of Debian and HP. And makes the point that HP aren't doing any of this to be "nice"; their primary responsibility is to their shareholders. Not surprising, but it's good that even with that criteria at the fore front Debian ends up a good idea for a large multinational. Managing 666 packages, Mart n Ferrari Mostly centered around the pkg-perl experience and the tools/workflow they have to help manage things. Impressive web tool (DEHS) to help track packages with new upstreams, issues or pending uploads. Quality Assurance in Lenny + 1 I can't remember a lot of this, which is a bit bad. I remember a discussion about whether we should release with orphaned packages, or if they should be removed. The argument for not removing them seemed to revolve around a theory that if they weren't buggy then what was the harm, the argument for was that if they were unmaintained and not really used than how did we actually know they weren't buggy, and was it reasonable that they potentially held up library transitions etc? Bugs in large packages Don Armstrong and ways in which the BTS can help people with lots of bugs. This (thankfully) doesn't affect me, but it was interesting to hear Don talk about his work on the BTS and his various ideas. I was sorry I'd missed his talk on SOAP access to it; I shall have to find time to watch the video. Tuesday
Debian and Ubuntu, Mark Shuttleworth The usual interaction with Debian stuff, including how we interact with our upstreams. If a bug is raised with an Ubuntu package then it might well be appropriate to raise it with Debian and upstream as well, but each set of people should be able to use their own bug reporting systems rather than having to go to a foreign system. I don't think it was actually said, but I guess the idea is that launchpad is the thing that will do this gluing together. He also talked about Ubuntu as an "experiment" rather than a fork of Debian; something that has potentially different ideas about how to do things but that these ideas may lead to things that should be fed back into Debian. The point was made that even if you consider Ubuntu a fork they've forked 9 times now; it hasn't been a case of forking once and diverging wildly since thast point. I have a few thoughts on all the whole Debian/Ubuntu stuff which I should really try to form into something coherant and post. I think it's important to take Mark's talk in the context of bdale's "Shareholders come first" point. Derivatives round table Didn't stay for most of this. Ubuntu, Debian-EDU (which I hadn't realised was a derivative rather than a team within Debian, but apparently there are various things it was much easier for them just to patch now and try to work towards a generic solution later), someone from Extramadura and someone from the Munich government Linux stuff. I'm sure I've missed someone off. tdebs/i18n This was a useful BOF. It helped that we said no to the usual video team requirement that if you want to speak you had to wait for the microphone. This works fine for a normal talk, but really impedes the flow of conversation in something like a BOF. tdebs are something that have partly come from a need of Emdebian to reduce installed package size and partly from the desire of the i18n team to be able to update package translations without having to do a full binary NMU of a package. We had some of the FTP team, the release team, the i18n team and Emdebian there and I think some progress has been made. There'd been various conversations had before this meeting which I think helped people think about the issues and objections so that we had answers by the time we all sat down together - an excellent example of the use of DebConf. DebConf9 C ceres Various bits of discussion about next year's DebConf in Extramadura. Temperature is likely to be an issue for me as they reckon it could easily get up to 40C! I'll melt! Venue sounds good; some queries regarding late night hacklabs and net connections to same, but I'm sure the networking team will sort it all out as usual. ;) DebConf10 bids Venezela and New York were both pitching. Lots of people don't want to travel to the US or think they'll have problems doing so (I hadn't realised there was such an issue for people from South America). I suspect various people will have issues with Venezela as well; I heard expressions of doubt over their political stability expressed. However I'd be happy to go to either (and preferably both! DebConf10 + 12 perhaps?) Speaking of which, what ever happened to the Sarajevo bid? If they're reading, have you considered DebConf11? Wednesday
A day trip to an Argentinian ranch and lunch was an asido. Fantastic food and a pleasant afternoon spent sitting in the sun chatting to people. That evening was the formal, but thanks to having stayed up until after 4 on Tuesday I had to wimp out and go to bed fairly early. Not until I'd seen the DPL dance though. :) Thursday
Internationalization in Debian I forget most of this other than pretty graphs from Christian regarding what's translated and what other languages we might have; e.g. you can consider South America to be covered largely by Spanish and Portuguese, or you can consider it to not be covered very much at all by the local indigenous languages. dh-make-webapp: yeah right! Mainly what I took away from this was "It'll never happen thanks to the fact that every web app author uses a different system" and that more work needs to be done on the web apps best practices document. I don't really do web apps, but having them easily installable on my systems is a good thing so I hope some standardisation within Debian comes from this. Best practises in team-maintaining packages Various team members got up to talk about work flow in their teams. Not unsurprisingly different things seem to work for different people. Predictable PRNG in the Vulnerable Debian OpenSSL Package Lucian giving his Black Hat talk about the OpenSSL issues we faced earlier this year. Some queries about automated testing and that it should have found this, which originally I agreed with until I thought about it - you'd have to have run > 65536 tests and compared all the data to find this; something like the FIPS tests against a single run wouldn't have shown any issues. Lucian wanted feedback on ensuring he was presenting the Debian side of things acceptably as well. Keysigning Run by Don Armstrong. Nothing to really remark except I think key signing attendance is dropping off after things like the Helsinki experience. Also I've now managed to get my new RSA key signed by keys other than my own (and I'll try to get sorted out to sign keys myself soon). Friday
LessWatts Intel's drive towards reducing power usage. Odd to hear such things from someone who wasn't Matthew Garrett and I think I'd heard most of it before. Debian technical policy update Sorry Manoj, I should have been paying more attention. Debian Policy is something I think is important, but I'm not enough of a nitpicker to really feel I can contribute a whole lot. Virtualisation in Debian - Present and future This was depressing. What I took away was "We had 2 forms of virtualisation in etch (Xen + vserver) and we're supporting neither for Lenny". As someone running a Xen machine this is problematic. The host does have the hardware support that would allow kvm, but I'm worried about smooth migration (it's a colo box). There was some mention of Xenner, which isn't packaged for Debian. I took a look at doing so but there are some worrying items in the TODO list (like, oh, locking to enable reliable SMP) and I've spectacularly failed to get it compiling so far. I should have another go. Emdebian update Neil Williams about where Emdebian is and waved his Balloon3 about. Some interest from the Openmoko guys and discussion about why it might be better than OpenEmbedded. And equally what it couldn't do that OpenEmbedded can manage (mainly very small installs; a minimal Emdebian install is 24MB+ and with X that goes up to 75MB+ I believe). netconf I'd never actually seen Martin talk about netconf before. Am impressive flow of control diagram. It all sounds quite complex for little benefit at present, but if he pulls it off then I can see it being a much more flexible replacement for the likes of Network Manager. Saturday
Lenny - The Road To Release Neil played with putting the heads of the release team on random images. And tried to tell us all how to behave during the release process in terms of what should and shouldn't be uploaded etc. Most of it is just common sense, but apparently everything he talked about he'd experienced. Also pointed out we were supposed to release in 3 weeks and didn't even have the appropriate kernel in testing yet so it's probably not going to happen. Colour me surprised. Sustainable Computing Low power consumption/affordable computing. Interesting points about the OLPC being used in the middle of nowhere with no chance of an Internet connection being close by compared to neighbours in large cities where people can't necessarily afford top of the line computers or individual connections - in this sort of scenario mesh networking is really viable in terms of getting people connected up. Multi winner voting Manoj needs pretty diagrams, probably drawn by Martin Krafft. ;) Semi-interesting discussion about multi-winner voting (e.g. SPI board elections) and how the current Debian voting system is completely tied to Debian's infrastructure eg the LDAP setup. Manoj would like to make it more generic so it could be used by other groups as well as for different sorts of votes in Debian.

As everyone can see in the graph of release critical bugs, the number of RC bugs in etch had constantly risen since the release (which was already noted in some other blogs) up until last week. Since I suspected that this number included a lot of false positives, I began to triage this list last week during Debconf. I started with identifying all bugs that were filed against the version in etch, but really only meant the package in testing/unstable (but can't be interpreted correctly with version tracking alone since the version in stable, testing, and unstable is actually identical). There are a lot of reasons why an RC bug might be valid for testing/unstable, but not for stable, even though they share the same package:

Library transitions.

While most cases of library transitions can be handled with targeted binNMUs these days, there remain a few cases where a sourceful upload is needed, e.g. for renamed -dev packages and necessary source changes to adapt to new APIs.

Build-Problems caused by toolchain changes.

Newer gcc versions are often more strict about what constructs they allow. This can cause build problems in a lot of packages once the default version used is increased. Other packages that regulary cause new build problems are linux-libc-dev and dpkg-dev. Since we only require that a package is buildable in the release it is contained in, these are not valid RC bugs for stable.

Changes in the RC policy of the release team.

One example during the lenny release cycle was the use of invoke-rc.d in maintainer scripts to (re-)start daemons. Bugs were filed against a lot of packages not using invoke-rc.d before the etch release but they were only declared to be of RC severity after etch.

etc.

So as the first part of my triaging efforts I tried to identify these cases. I also looked for bugs that were listed as affecting etch due to incomplete version information (i.e. if there is no version given, the bug is assumed to affect all versions). As you can see from the bump in the graph I was able to identify about 200 bugs that met one of these conditions. We should avoid in the future to let the number of false positives grow to such large numbers. Everyone can help with that:

Maintainers

If you get bugs reported without a version number and you can verify that this bug was not present in an older version of the package, add correct "found" information. If you get a bug reported against a version that is both in stable and in testing/unstable, but not valid for stable, tag the bug appropriatly. I would recommend to err on the side of false positives though instead of on the side of false negatives!

Mass-bug filers

Most mass-bug filing that involve RC bugs should use tags to avoid creating false positives.

QA Group

Bugs filed about the proposed orphaning or removal of packages should usually be tagged, since only in very few cases these actually warrant any changes in stable.

At this point you probably ask yourself: What are the appropriate tags? This is much less clear than one might hope, since the involved tags (<suite>) changed/lost their meaning somewhat with the introduction of version tracking. Following my question about the appropriate tags on debian-release the release team and Don Armstrong for the debbugs maintainers seem to have agreed on their new meaning: A bug with suite tags affects the intersection of the set of suites indicated by its version information and the set of suites indicated by its suite tags. Next post: What about the other 600 RC bugs in stable?

What I liked

• Excellent organization, orga team fully deserved all the praise they got.
• Meeting people - it was the first DebConf I attended in person, so it was a pleasure to meet lots of folks whom I’ve only known online before.
• Quite a few interesting talks (videos are available, or will be available shortly, in DebConf8 video archive). Particularly recommended: quality assurance talks/BOFs by Lucas Nussbaum, BTS development progress by Don Armstrong, method diffusion in large volunteer projects by Martin Krafft, talk and debate on OpenSSL security issue by Luciano Bello, various lightning talks.
• Deserving a special mention, a talk by Mark Shuttleworth on Debian and Ubuntu relationship. I thought that he said all the right words and, judging by reactions, attitude towards Ubuntu has changed significantly during the last year, turning from hostility to peaceful cooperation.
• Argentinian food: steaks, empanadas, alfajores.

What I did not like

• People pay much less attention to fixing RC bugs than they used to, the two BSPs organized during DebConf8 attracted only 3-5 people.
• Some nice ideas being thrown around without anyone volunteering to work on them. Not really surprising, given that most of the core teams are short on manpower.
• Almost complete lack of events targeted at engaging users and beginner contributors.
• Quite a few specialized talks, interesting (IMHO) to only a minor percentage of the attendees.
• Lots of discussions with few or no specific decisions or action items.
• Pretty long trips to and from Mar del Plata (about 30 hours door-to-door travel time for me), luggage was lost for 2 days on the way there.

What I did

• Attended about 75% of talks, tried to contribute to discussion in constructive, non-flamy ways .
• Participated in BSPs, contributed debugging information, patches or fixes for about a dozen of release critical bugs, started triaging sparc-specific bugs.
• Started working on updating the Debian kernel handbook for Lenny, about 1/3 done.
• Gave a “Google and Open Source” lightning talk.

Continuing from where we left off… The lower bound for me becoming a DD was 8th Feb ‘98 when I applied; for comparison, the upper bound as best I can make out was 23rd Feb, when I would have received this mail through the debian-private list:

Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze 
To: Debian Private 
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week.  Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers.  These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
    Anthony is going to package the personal proxy from
    distributed.net - we don't have the source... He may adopt the
    transproxy package, too.
Regards,
        Joey

I never did adopt transproxy – apparently Adam Heath started fixing bugs in it a few days later anyway, and it was later taken over by Bernd Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I did do other things instead, which brings us back to where we left off…

---

• Crypto in main: It’s getting hard to remember the days when strong crypto software was classed as munitions and even getting a web browser to do SSL properly was a legal challenge; but for a long while that’s how it was, and as a result we had to keep all our security tools hosted separately to our main, US-based archive. The laws for that changed in early 2000, introducing a new exemption to the prohibition for software whose source code was available royalty-free (I think they called it “public source”). Unfortunately there were still drawbacks: it wouldn’t apply to some stuff in non-free, it wasn’t clear how far you had to go with the source code (is libssl’s source enough, or do you need the source for the apps that use ssl too?), and the biggest problem was you had to notify the export bureau and the NSA for everything you wanted to distribute. And all of that’s couched in the sort of confusing language you’d expect to find in, well, export regulations. So we ended up getting nowhere on merging crypto into the main archive for a long while because we couldn’t be confident of what we actually needed to do. We’d more or less already missed the opportunity to do the merge for the potato (2.2) release because it was frozen more or less exactly when the new regulations came out, and according to my mail archives Ben Collins (DPL at the time) got a team organised to review the legal issues by mid-May 2001. By July 2001, though, we still weren’t really getting anywhere; the lawyer we were talking to was looking at the ENC exception (which was for closed source stuff, and requires an active review by the BXA), instead of the TSU exception (which just requires notification). While it wasn’t terrible legal advice – following the ENC exception had a lower risk of misunderstandings on our part leading to problems later – it wasn’t useful in achieving our aims, ie, getting crypto stuff into main with a minimal level of ongoing effort, as well as a minimal level of risk. So moving onto August, we’d moved on from the lawyer we’d been using for this and other issues, to talking to a lawyer who specialised in export issues (and whose time was being covered by HP). That actually got us somewhere, with the end results being a matter of public record – we got the advice we wanted by November, we got a new incoming system so we could make sure we didn’t publish anything we hadn’t advised the NSA and BXA about, and most of all, we got cryptographic software in main for woody’s release. ssh at standard priority, apt by default checking archive signatures before downloading code to run as root, iceweasel coping with https:// urls out of the box all suddenly became possible, rather than artificially blocked due to pointless legal constraints. Yay! The way we notified BXA/NSA was somewhat interesting – we ended up notifying once for each package, when it passed through NEW: which is easy to automate, and limits the amount of software we block from review by other developers as best we can. OTOH, it also means a lot of notifications: the initial notification was a huge box of paper that got faxed off (there should be pictures somewhere on the net, but I don’t know where), and the vague hope that the ongoing reporting would not only comply with the regs, but manage to be something of a denial-of-service by compliance. As it turns out it apparently got noticed, with the following mail arriving in September 2005:

  From: Encryption 
  Date: Fri, 23 Sep 2005 12:51:02 -0400
  Subject: Addition to Debian Source Code updates
  Dear Mr. Collins,
  Your diligent reporting of updates to the Debian source code to the Bureau
  of Industry and Security has been an excellent example of perspicacity.
  However, you no longer need to do so per the following update to the EAR:
  [...]
  

  (The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)
• Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
• Playing other people for suckers: with woody released, the whole "redo to release process" thing was essentially done -- it had been implemented, it had worked all the way to getting a release out, and in a fair few respects had improved things. Instead of the eight months of hand-approved uploads for the potato freeze, things had gone it automatically, albeit with gradually stricter constraints, right up until April; and even when the security problems delayed things, the manual updates only lasted a bit under three months. So at that point I was pretty happy, and looking forward to making things work a bit better and basically passing the buck to someone else. The first bit of buck passing that worked exceptionally well was jumping on Colin Watson, who'd been offering some debbugs patches on IRC, and after a delightfully brief discussion with some of the other debbugs folks, got getting him added to the group and able to make changes directly on the site. His advogato post the next day was:

  Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.

  There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.

Geez, this was meant to be briefer...

Having had a little discussion with Stefano Zacchiroli aboutdebian/changelog editing and bug number completion, Idecided I'll make the 'apt-listbugs list' command a bit moreuseful.It now has two new features.--severityall option to specify all severities, and you canspecify the current version with PACKAGE/VERSIONsyntax. These functionalities should be available in the0.0.79 upload.It also uses the shiny new BTS SOAPinterface, and no longer relies on merkel.debian.org, thanks to help from Don Armstrong.To find a bug that is not yet closed on apt-listbugs 0.0.79, you'll ask for it like this: apt-listbugs list -s all apt-listbugs 0.0.79

Just prior to the “State of the Coffee Cup” talk on Sunday, Tom Marble sent a quick invitation to Steve Langasek, Sam Hocevar and myself to have a chat with Simon Phipps about the CDDL and some of the concerns that have been raised on the debian-legal list lately – particularly about choice of venue. Unfortunately in the ten or fifteen minutes between the mail and the meeting, we couldn’t find Sam, but we managed to grab Don Armstrong to join in instead. It’s a couple of days later, and I’m going from memory, not notes, so this is paraphrasing. Simon’s primary concern was one of predictability – Debian accepted the Mozilla Public License back when it was released (and prior to Mozilla and other software tending to get dual licensed under the GPLv2) which is what the CDDL was based on and contains almost the exact same terms. Simon’s comment was that if you’ve accepted that then, reviewing new licenses from scratch and coming up with different results really makes it hard to work with you, and worse makes it look like you’re basing your conclusions more on who proposed the license rather than what the license actually says. Don and Steve seemed to mostly appreciate that point, but still thought that choice of venue was harmful and unnecessary, and that it’d be nice if Sun – as pretty much the primary organisation currently behind any of these licenses – would take some steps to reduce that harm: limiting choice of venue to when both parties in a dispute are multinational, for example. Simon’s concern there was that updating the CDDL would require a lot of effort internally – getting buy in from all the groups in Sun using the CDDL, as well as getting the wording changes approved from the appropriate legal advisors, and convincing the lawyers of Sun’s commercial partners that the changes weren’t going to be a problem later; and committing to all that work when a new versions of the GPL is about to be released and it might be a better thing to work on getting the relevant software available under that, or even the GPLv2. On the other hand, Simon thought that making (binding) statements about Sun’s interpretation of the license seemed to (eventually) work reasonably well for the DLJ, so might be something that can be done again for this issue. And while that only counts for Sun, we can fairly easily ask if other authors of CDDLed stuff agree with Sun’s interpretation for their software, and only worry about possible problems if it turns out they don’t. That’s pretty much where we ended up I think, with Simon suggesting that we work out what exactly needs to be clarified with Tom, and then get it passed back up to Simon to get signed-off on. And hopefully that’s what’ll happen over the next little while. :) (The somewhat more interesting question of whether we can combine CDDL’ed OpenSolaris (in particular Solaris libc) with GPLed userspace tools such as dpkg to produce a Debian OpenSolaris distro is still up in the air – Sam’s currently waiting on a response from the FSF legal team on one of the questions that concerns Debian, aiui; but they’re currently flat out working on GPLv3 as you might imagine. Oh well – in the meantime, there’s always Nexenta!)

Thanks to Don Armstrong's improvements to the performance of version-tracking in the BTS and Anthony Towns's tweaks to dak, as of the middle of last week, all NMUs uploaded to Debian unstable will cause the bugs mentioned in their changelogs to be marked as closed in that version, instead of just being marked as fixed. This is a great benefit to the release process, since previously, bugfixes in NMUs were still falling off the radar as soon as they were uploaded, with no automatable way to check whether a given update stuck in unstable fixed release-critical bugs that we needed to have in testing for the release. So these guys get a big thank you from me for helping to ensure etch only ships with the bugs we want it to ship with. ;) The new setup also has the advantage that bug submitters finally get the same, real email for bugs closed in NMU as they do for bugs closed in MU, instead of being left in the dark as they were before. But that only takes care of bugs closed in NMUs that happen between now and the release -- it does nothing for the roughly 1200 RC bugs that were already fixed in prior NMUs that haven't been acknowledged by the maintainer. Who knows if any (or how many) of those are still open in etch right now? Rather hard to tell when we don't know what version closed them, isn't it? So with a lot of help from Adam Barratt this weekend, we've marked about 800 (egads) of these RC bugs as closed in the corresponding NMU versions, with a brief note to the submitters. In the next couple of days, we should find our way to the end of the list, at which point we can think about ignoring the 'fixed' tag over on turmzimmer.net. Also fixed now is bug #388431, so people should be able to stop worrying now about their users chewing up the CPU with real-time scheduling. Nothing like a maintainer upload of a base package one year in the making, being uploaded after it's been frozen. So make that... 801 bugs closed?

Happy new year, everyone! I was away over the weekend, working hard on Ignition 2006, and I missed the big day here in front of the computer. Instead I was out under the stars with Montreal Burners, having Burning Man fun out in the wt:Eastern Townships. I'm not sure if it happened this year, but I think next year it would be great to have a Debian:BSP in wt:Black Rock City. OK, sure, it'd be super-nerdy, and the connectivity is pretty spotty, but there are some long, hot afternoons out there and I know that there are at least two DDs that are on the Playa pretty regularly (me and Don Armstrong). I wonder if there are more? I wonder if we had a BSP, if lots more would show up? tags: debian don armstrong bruleurs new year french revolutionary calendar

Usability So, my current computer usability problem has to do with the rockin' secure shell program OpenSSH. Here's what happens: I'm on a box and I have a new login goin' on. And I have to ssh to another box, and I get the message:

Enter passphrase for /home/evan/.ssh/id_rsa: 

This happens because I haven't run ssh-add when I logged in, to store the passphrase for the key with the current ssh-agent. So now I have two options:

1. enter my password and then possibly forget to run ssh-add before running ssh again
2. kill the current ssh instance, run ssh-add, then run ssh again

Both options suck. What would be nice is if I could enter my passphrase, and have that count as if I had run ssh-add. Like, after I enter it, the ssh client could say:

Add this key to your current ssh-agent session [Y/n]?

...and then ssh would add the key, like ssh-add does, and continue with the login. Wouldn't that be great? I think this is the biggest usability problem I run up against in my daily work life. Which, y'know, is pretty good. [You might want to look into libpam-ssh] [See also http://advogato.org/person/mbrubeck/diary.html?start=90 ] tags: ssh usability wishlist

Wikimania 2007 in Taipei I have to say that I'm a little wistful that wt:Alexandria wasn't chosen for Wikimania 2007. We had a really good bid to hold the event in Alexandria at the Bibliotheca Alexandrina, the "new" Library of Alexandria. I was getting pretty excited about going to the Mediterranean next year. But I think that Taipei is going to be a fantastic place to hold Wikimania, too. Holding the event in wt:East Asia will make it much easier for people there , in wt:Southeast Asia, and in wt:Australia or wt:New Zealand to come to the event. A Wikimania in East Asia will focus attention on the non-English-language and non-European efforts of the Wikimedia Foundation. Taiwan also has a really strong local Wikimedian group, with Wikimedia Taiwan soon on its way. Finally, a Wikimania in wt:Taiwan will re-emphasize the wp:Blocking of Wikipedia in mainland China. Jimmy Wales has said on the record that Wikimedia will not censor its Chinese-language projects to comply with the PRC's firewall (the so-called wp:Great Firewall of China), and I'm sure an official event in the ROC will further highlight that point. Personally, I'm looking forward to a trip to Taipei, which will be a good excuse for some more exploration of Taiwan. And I want to congratulate the Taipei bid team. I was impressed by the amount of work that went into the Alexandria bid, and I'm sure they did a lot of work for Taipei, too. I know the Alexandria crew is optimistic for next year: starting the steps for making a Wikimedia local chapter in Egypt, and continuing to develop relationships with the local technology companies as sponsors. Should be interesting... it might be worth a trip after all! tags: wikimania wikimania 2007 alexandria taipei

In hacking apt-listbugs and getting something usable out ofdebian.org machines, and to fight against the inertia of notallowing direct access to db-h, I decided to give theSOAPbackend a try.Apart from the problem of non-existing documentation and non-functional implementation,with much help from Don Armstrong, I got something working.Due to the fact that only one HTTP request is required for obtaining the bunch of bug reports, it might be actually suited for apt-listbugs. I'm a bit worried about the load, tho'.soap4r was also very much painful to work with, with its lack of useful documentation.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

To infinity, and beyond! -- Buzz

[Debian]

I should write about this a few days ago but didn't have the time. Sorry. Well, these are great news (at least for me), a few days ago I sent the second part of my T&S and already got approved. My AM (Hi Cl ment) also pointed out a few changes that were needed in my packages that are already fixed and uploaded; Cl ment already sent the report and considering that, I'm now waiting for the Front Desk to review my application (and after that, DAMnation. I'm happy! I also finish the adoption of xless and levee. I still have to finish the MyPasswordSafe adoption, but before I have to fix a RC bug related to the use of sudo as the gain-root command (instead of fakeroot) in the alpha buildd. Thanks neuro that already give me a few tips on how to solve it.

Following the random ideas season:

• Next week, Extremadura will host the i18n Debian people, the idea is to discuss lots of ideas, specially i18n Infrastructure, but not only discuss, also code a lot!
• I do not like the idea to have sourceless firmware in main and I really like Don Armstrong proposal on that subject.
• I still have to finish the desproxy, tuxfrw and thumbs packaging work to get it in time for etch.
• I'm wondering how a tally sheet with more than 10 choices looks like

[Anti-SPAM season]

Like a lot of people already did, in the last two weeks I've been fighting SPAM in my company and also on the server of Free Software Projects that I'm part of the System Administration Team. In most cases I'm using postfix with clamscan and postgrey, but I will switch to amavisd-new to use SpamAssassin (with razor/pyzor). But I'm still studying the various alternatives in a Debian Sarge system.

Hey silva, thank you! (Journeyer certification).